IBIS Macromodel Task Group Meeting date: 18 August 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak Curtis Clark Avago (LSI) Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - None. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Todd: They look fabulous. - Todd: Motion to approve. - Arpad: Second. - No objections. ------------- New Discussion: Info, Out, InOut BIRD draft: - Arpad: Last week we had a discussion on Info, Out and InOut, discussing how to tighten up the spec on it. We could have a new branch, so if a parameter ends up in the spec it won't lead to parsing issues. We could have a sub-branch under Model Specific but agreed it wouldn't be a good idea so the DLL wouldn't need to be rewritten if the parameter becomes standardized. I would like to make a decision today on what the rules should be. - Todd: What problem are we trying to solve? - Arpad: His understanding is that one of the main strengths of IBIS is portability. If we have Model Specific parameters with these usages, a model could become non-portable and IBIS will become less usable in the end. - Todd: So, the problem is that parameters that get put in the model affect how the model interacts with the simulator, and these are not part of the existing definitions of parameters. Are we trying to prevent it from happening, acknowledge it happens and standardize it? What is the goal? - Arpad: The goal is preventing EDA vendors from hearing complaints about models not working in all tools. We need to make it clear that certain features are for certain tools. - Todd: It is a delicate topic of standardizing the non-standard. So, it seems we are saying that if you work outside the standard, then you should identify it clearly with this mechanism. We are acknowledging that this happens. - Arpad: If we make a model that works in only one tool, is it an IBIS model, since it doesn't follow the spec? - Todd: So are we going to say that these models are ok? - Arpad: The spec does allow now models that will be proprietary, due to a loophole. This is mostly AMI-specific. - Ambrish: Why hide behind the spec and pass something that will for sure not work in other tools? Why not use comment characters so the parser doesn't choke? We have used this before and it has worked. - Walter: How can any Out or InOut parameter cause any tool to have problems? - Ambrish: You are hiding behind the Out parameter to see different results in different tools. - Walter: What if a manual that came with the model reports what an Out parameter does and issues warnings? If the model maker documents what the Out parameter does, and an EDA tool chooses to read that parameter or the user does, why should we prevent that from happening? - John: The Model Specific branch is for this type of information already. - Todd: Arpad is right in saying there is a loophole. Results can be affected by these Out parameters. - John: Model Specific parameters can affect the output by allowing the user to change certain settings. But there can be tool-specific implementations. - Ambrish: We could prevent Model Specific parameters from being Info so that they are only used by the tools. - Todd: So we are trying to address model portability between tools. Are we trying to tell EDA vendors their simulator shouldn't recognize specific parameters and do special things? Or are we just trying to let people know this is happening in a standard way? - Arpad: We can allow this, but we shouldn't lead users into thinking the model is completely IBIS compliant and will work in all tools. - Todd: Users don't always understand nuances of the standard, don't want to, and don't want to get into details when they just want to get their work done. He has spent a lot of time telling customers why certain models don't work. He learned to find ways of just getting models to work. Support for Touchstone files is an example. You'll get the same result just dropping the S-parameter in the schematic. - Walter: You won't get the same result. The model says to use a specific Touchstone file. But the user gets things confused half the time and sets it up wrong. Model makers don't want this source of error. They just want it linked in the AMI file. SiSoft did something proprietary to fix the issue. - Todd: There are cases when tools are innovating, and hopefully they are at least telling people what they are doing. There is a point when this solution gets brought to IBIS. If it isn't accepted, then at some point models need to be rewritten to support a standard way. - Ambrish: When does the reconciliation process happen? How should we prevent proprietary methods from continuing to be used and not get updated to use standard methods? How can we move Model Specific parameters back into the spec? - Radek: There have been discussions that all the simulators don't know what to do with the Model Specific parameters. - Arpad: What if we suggest that Model Specific parameters can only have In types. The parser could allow Out but flag it with a message. - Todd: There are good uses for Out types. - Ambrish: Can we say that Info is not allowed? That type is meant for the tool only. - Todd: That is stifling innovation. - Ambrish: The parser could issue a warning. - Radek: In that case the simulation should error out if the parser fails. - Todd: There are three parts to this. Can we advance the standard and allow model portability with information sharing? There is then a responsibility to bring new ideas to the standard. Then There is a time when models have to be brought into compliance. - Ambrish: What can you do when a parameter notifies you that a model may work differently in different tools? - Todd: It could be put in Reserved Parameters and cause a parser issue. One thing is that we could use the notification method of comments such as "|SiSoft". The burden is not legislation but notification. Or we can come up with a new method. - Ambrish: The parser does the job of notifying you of potential issues. - Walter: It seems best to use the comment field when there is an advanced feature. - Ambrish: This means you can't legislate any way of controlling this. But it is a good way of notification. - Walter: In reference to Radek's comments, making Model Specific parameters that are Out was not a loophole. It was specifically intended to do these kinds of things. That was the mechanism for experimenting with new things that could go into the standard. This was not a loophole. - Ambrish: Is there any issue with a parser warning that parameters in Model Specific may cause differences in different tools? - Todd: Maybe we should make a legitimate place for these parameters. If we just take Info type Model Specific parameters and flag them, there are workarounds like making them In type so they don't generate parser messages. Generating parser messages does create a tone of models being bad. It would be better to legitimize the model innovations. - Walter: Motioned to table the unofficial BIRD and continue with the way things are handled now. No second. - Arpad: Coming back to how to make this legitimate, John said there was an issue with my previous suggestion, but I would like to understand better. Can't we have a way to pass proprietary parameters by inventing new Usage types, such as InfoProrietary, OutProprietary, InOutProprietary and use these for the non-standard, innovative parameters? - John: InOut does the legitimate thing and Info does the proprietary thing. - Radek: When you put something into the Model Specific section, you don't pass the branch name into the DLL. We are asking for a better established way of informing the user. We have a description string in the definition of the parameters. That could be used to inform the user. - Arpad: The parser can't flag that. - Radek: The parser could flag a Model Specific section with Info or InOut, noting that the model could be proprietary. - John: Jitter parameters in the Model Specific branch could be Out. There is a hole for notification. - Arpad: I think we should continue thinking about a solution to this. - Todd: There has been better agreement on the notification aspect of this. We want the user to easily see that a model may only work in specific tools. ------------- Next meeting: 25 August 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives